1. Field of the Invention
The invention relates generally to extending the capabilities of network security. More particularly, the invention relates to a system and method for selecting and performing different security format conversions in a data center based on security format information received from a network.
2. Background Information
Cell phones are often used to exchange sensitive personal and financial information over unsecure public networks. Accessing information from a financial account over the Internet is one example. Security solutions that encrypt data at the cell phone and transmit the encrypted data over the public networks have been devised to reduce the likelihood of an unintended recipient discovering the sensitive data. The goal is to provide end-to-end security between the cell phone user and a recipient. However this goal has been limited by a Wireless Application Protocol (WAP) gap wherein conversion from one security standard to another is performed within an untrusted intermediate WAP gateway that links the wireless access network to another public carrier network and renders the sensitive data unencrypted and vulnerable to attack even if only for a brief period of time.
FIG. 1 shows a system 100 that allows a cell phone 110 to exchange secure data with a server 170 subject to the limitations of a WAP gap 150. The cell phone 110 sends a Wireless Transport Layer Security (WTLS) encrypted request using either Wireless Datagram Protocol (WDP) or User Datagram Protocol (UDP) as a transport protocol to a wireless network 120. The request may include an access identification and password to access a financial account. The wireless network 120 receives the request and sends the request to a WAP gateway 130.
The WAP gateway 130 receives the request and includes a converter 140 to perform a first conversion 142 from either WDP or UDP to Transmission Control Protocol (TCP) and from WTLS to Secure Sockets Layer (SSL). During the conversion between WTLS and SSL, the secure data passes through an unsecured and vulnerable state that is susceptible to attack. Typically, the WAP gateway is owned and operated by a third party mobile operator. Leaving the sensitive data unencrypted in the hands of an unknown and untrusted third party is not a good practice. After the conversions the WAP gateway 130 sends the converted request to the Internet 160.
The Internet 160 receives the converted request and sends the converted request to the server 170. The server 170 receives the request in TCP and SSL format, converts from SSL format to a plain data format, and may run application scripts such as CGI scripts 180 to access content 190 and generate an SSL encrypted response comprising the content 190. The server 170 uses TCP to transport the response in SSL format to the Internet 160. The Internet 160 receives the response and sends the response to the WAP gateway 130. The WAP gateway 130 performs a second conversion 144 from TCP to WDP and from SSL to WTLS. The WAP gateway 130 sends the converted response to the wireless network 120, which sends the response in WTLS encrypted format to the cell phone 110.
FIG. 2 further illustrates the vulnerability of data in a WAP gateway 200 having a WAP gap 250. The WAP gateway 200 receives WTLS encrypted data, which is conceptually represented by a WTLS security envelope 210. The WAP gateway 200 decrypts the WTLS data, which is conceptually represented by the open WTLS security envelope 220. Once decrypted, the data resides in the memory of the WAP gateway 200, at least for a brief period of time, as unsecure data that is in plain view 230. This vulnerability is known as the WAP gap 250. The WAP gateway 200 then encrypts the data in SSL format, as represented by the insertion of the data 230 into the open SSL security envelope 240 and subsequent sealing of the envelope 260. The SSL encrypted data, which is conceptually represented by the SSL security envelope 260 is provided to the Internet. As indicated by the bi-directional arrows, the WAP gap 250 may also be encountered when conversion is performed in the reverse direction from SSL to WTLS. Accordingly, as a result of the WAP gap 250 the data resides in a vulnerable, unsecured state that is under the untrusted control of the WAP gateway 200 and may be subjected to a man-in-the-middle attack.
FIG. 3 shows a prior art system 300 to avoid the WAP gap. A cell phone 310 exchanges WTLS data with a WAP gateway 320. The WAP gateway 320 sends the WTLS secure data to a trusted WTLS/SSL conversion system 330. The conversion system 330 resides at the same physical location as the WAP gateway 320 and is partially controlled by a party that controls the server 340. The WTLS/SSL conversion system 330 converts between WTLS and SSL by passing the data through an unsecured plain data state. Accordingly, this solution does not provide an end-to-end solution in which data is always in encrypted format. Also, although conversion in the WTLS/SSL conversion system 330 may be comparatively more trusted than conversion in the WAP gateway 320, the conversion system 330 resides at the physical location of the WAP gateway 320 and therefore the party of the server 340 does not have entirely trusted control of the conversion system 330. An additional disadvantage is the increased latency introduced by sending WTLS data to the WTLS/SSL conversion system 330 and awaiting responsive SSL data from the system 330. The WAP gateway receives the converted data in SSL encrypted format and provides the SSL encrypted data to the server 340 which runs CGI scripts to access data and format a response. The need to perform both a conversion from WTLS to SSL and then from SSL to plain data is yet another disadvantage of the system 300.